Fixes #650

Summary

• add the separate authenticated policyengine-simulation-entry FastAPI
  service on Cloud Run while retaining the existing Modal gateway and executor;
• preserve the existing request/response contract and pass simulation job IDs
  through unchanged;
• keep caller authentication separate from the entrypoint's machine
  authentication to Modal;
• replace opaque mapping boundaries with named Pydantic, root-model, and
  TypedDict schemas shared by the entrypoint, gateway, executor, OpenAPI, and
  generated client;
• deploy and unit-test the Cloud Run entrypoint, Modal gateway, and Modal
  executor in three parallel jobs for each environment;
• publish routing only after all three service jobs pass, then run full
  integration tests followed by a separate authenticated test job;
• require the complete beta sequence to pass before production begins;
• qualify Cloud Run candidates through generated tagged URLs without requiring
  a beta custom domain;
• automatically assign production service traffic to the exact tested Cloud
  Run revision only after the complete production suite passes;
• verify the promoted revision through the stable service URL and restore the
  exact previous revision if immediate post-promotion checks fail; and
• keep one-time project, identity, WIF, secret, DNS, and domain setup out of
  committed bootstrap automation.

Why

Stage 5 establishes the permanent simulation control-plane boundary before
later stages migrate routing, durable state, and worker responsibilities. The
existing Modal gateway remains the authenticated backend and rollback target.

The entrypoint does not need its own URL as runtime configuration. Cloud Run
provides tagged candidate and stable service URLs, and the existing .modal.run
upstream restriction prevents recursive configuration. The service returns its
Cloud Run revision in a response header so deployment checks can prove which
exact revision a URL serves.

Deployment safety

The production promotion job records the currently serving revision before
deployment. Before changing traffic it verifies that:

• stable traffic has not changed since the candidate was created;
• the target revision belongs to the intended service; and
• the target revision reports Ready.

Promotion and rollback always name exact revisions; they never use LATEST.
Repository-level deployment concurrency prevents overlapping releases.

This automation changes only the Simulation Entrypoint Cloud Run service's
traffic. It does not change API v1 revision percentages or activate API v1's
entrypoint migration flag.

Validation

• Repository unit suite: 464 passed across the executor, entrypoint, gateway,
  shared contract, and observability packages.
• Simulation Entrypoint: 51 passed.
• Deployment promotion/rollback tests exercise successful promotion, exact
  rollback, and refusal to overwrite an intervening traffic change.
• Ruff format/check and Pyright pass for the changed entrypoint code and tests.
• Changed shell scripts pass Bash syntax validation.
• Changed deployment workflows pass Actionlint.
• YAML parsing and git diff --check pass.

Live integration and authentication tests require deployed candidate URLs and
protected environment configuration and remain explicit deployment jobs.